Tech Arsenal 1

home *** CD-ROM | disk | FTP | other *** search

/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-05 / xgate200.zip / XCHARON.ZIP / XCHARON.DOC < prev

Wrap

Text File | 1992-11-20 | 29KB | 793 lines

+------------------------------------------------------+ | | | | XCHARON 2.0 XCHARON 2.0 | | | | | | Running XGATE With Charon Running XGATE With Charon | | | | | | +------------------------------------------------------+ XCHARON - Running XGATE With Charon ---------------------------------------------------------------------- Introduction Introduction XGATE can be run using either XSMTP or Charon as its SMTP agent. XSMTP is a native add-on module for XGATE from DAC Micro Systems that runs in the same computer and requires the PC/TCP kernel from FTP Software. Charon is a separate SMTP gateway developed by Brad Clements of Clarkson University that requires its own computer. This documentation describes how to use Charon as the SMTP mailer by using the XCHARON.COM driver supplied with XGATE. Using XSMTP as the SMTP mailer is described in separate documentation. Charon isn't quite as powerful as XSMTP, doesn't match its level of performance, is a little more complicated to set up, and requires a separate computer - but what do you want for free? Even so, however, Charon is still a very robust, reliable, and professionally developed SMTP agent. As of this writing Charon is freely copyable software. But since Brad makes a stipulation in his documentation that Charon not be combined with programs that are for sale, we can't include it with XGATE's distribution files - you have to obtain it separately. Charon can be found on Compuserve under NetWire, by anonymous FTP from Clarkson University (omnigate.clarkson.edu), or from our own bulletin board (805-264-1219). Charon by itself would not be compatible with XGATE or MHS, it was originally designed to work with Pegasus mail. (A mail system which actually uses the SYS:MAIL\userid directory structure.) XCharon is a driver supplied with XGATE that seamlessly alters Charon's behavior to be compatible with XGATE's operating environment. XCharon was developed for Charon version 3.4. Since XCharon is very specific to the way in which Charon accesses the Novell API, no guarantee is made that XCharon will work with versions of Charon older or newer than 3.4. Dave Frailey DAC Micro Systems Voice: 800-776-1322 Voice: 805-264-1700 BBS: 805-264-1219 i XCHARON - Running XGATE With Charon ---------------------------------------------------------------------- Contents Contents INTRODUCTION...................................................I REQUIREMENTS...................................................1 CONCEPT OF OPERATION...........................................1 INSTALLATION...................................................3 Installation Steps..........................................3 Configuring CHARON.DAT......................................4 RUNNING CHARON.................................................7 What XCHARON Does To Fool CHARON............................7 ii XCHARON - Running XGATE With Charon ---------------------------------------------------------------------- Requirements Requirements When you run XGATE using Charon as the SMTP mailer, a separate computer is needed on which to run Charon. Charon requires a packet driver (as in one of the Clarkson Packet Drivers) to communicate with the ethernet card, so if you don't have a packet driver for the type of ethernet card that will be used in Charon's computer, you'll also need to download the Clarkson Packet Drivers or contact the manufacturer of the ethernet card. A current copy of the Clarkson Packet Drivers can be found on Compuserve's NetWire, on our own bulletin board, and various Internet hosts like omnigate.clarkson.edu. This documentation is not an authority on Charon's requirements, you should consult Charon's actual documentation for specific details. Charon does tax the CPU quite a bit more than XGATE though. If it were me I'd run Charon on at least a faster 286-based computer. Concept of Operation Concept of Operation How does it work? Its not really that complicated.... It takes two PC's to do the job. One PC runs Charon (driven by XGATE's driver; XCharon), and the other runs XGATE. The PC running Charon does all of the receiving and sending of SMTP mail. When it receives new SMTP mail, the XCharon driver fools Charon into thinking the user is always valid and also fools Charon into putting the message into the proper Novell job queue where XGATE expects inbound messages. The other PC running XGATE, knows which queue Charon is being fooled into putting inbound messages and scans it on a configurable basis for new SMTP mail. The PC running XGATE also scans the MHS gateway directory for new outbound MHS mail during the same cycle. When XGATE detects a new outbound MHS message, it converts it to an RFC-822 compliant SMTP message and places it directly into the Novell outbound SMTP job queue. The XCharon driver also fools Charon into scanning this queue when it looks for outbound SMTP messages. Philosophically, all inbound SMTP messages received by a SMTP gateway for MHS should be considered destined for a MHS user, and received without question. The messages are then converted and passed to MHS for routing. If there's a delivery error, MHS will send an error 1 XCHARON - Running XGATE With Charon ---------------------------------------------------------------------- message back to the SMTP user a few minutes later. Furthermore, one SMTP gateway should be capable of sending and receiving messages for any number of MHS hosts. Without XCharon's influence, Charon would like to login as a Novell print server and use Novell print queues to hold SMTP messages in work. The names of the print server and print queues are normally defined in Charon's CHARON.DAT file. But when XCharon is running Charon it forces Charon to log in as a different type of job server, and it also forces Charon to use different queues for inbound and outbound messages. So when XCharon is running Charon, what is defined for the names of the print server and print queues in Charon's configuration file won't make any difference. All of this stuff about Novell job servers, job queues, and the appropriate privileges for each, are installed automatically in one easy step by using XGATE's setup program (XSETUP). 2 XCHARON - Running XGATE With Charon ---------------------------------------------------------------------- Installation Installation Installing Charon is not a cake-walk. It does require something of an understanding of TCP/IP based networks. If you don't feel comfortable with these types of questions, you may want to seek the aid of someone who is. As with XGATE, Charon should also be installed on the local hard disk of a PC connected to the network. You can try installing Charon on a network drive, but when Charon terminates and returns to XCharon, XCharon will automatically log itself out from the file server. Whatever method you are using to run XCharon would then have to be capable of relogging or reattaching under privileges that could re-run XCharon from wherever you installed it. Installation Steps Installation Steps 1. Make a directory to hold Charon's program files on the computer that will run Charon, and extract Charon's files to it (usually a .ZIP file). 2. Copy XGATE's driver, XCHARON.COM, into that directory. 3. Setup the computer that will run Charon to use Clarkson's Packet Drivers. The packet drivers are supplied separately from either Charon or XGATE. Charon's documentation provides some instructions on how to use the packet drivers. 4. Edit Charon's configuration files, CONFIG.TEL and CHARON.DAT to reflect your installation. A sample CHARON.DAT configuration file is supplied with XGATE since its quite a bit less complex than that which Charon is normally capable of using. When you run Charon, do so by running XCHARON.COM. Do not run CHARON.EXE directly. XCharon will automatically run CHARON.EXE. Configuring Charon for use with XGATE is quite a bit easier and much less complex than installing Charon by itself without XGATE. Where things differ between a normal Charon installation and our installation is mainly in the CHARON.DAT file. The CHARON.DAT file contains configuration information that Charon uses to deal with the Novell side of the house. Most of what we need to change in there can easily fit on one editing screen. 3 XCHARON - Running XGATE With Charon ---------------------------------------------------------------------- Charon also uses a file called CONFIG.TEL which contains information generic to the Clarkson family of TCP/IP applications (such as their Telnet and FTP programs). The format of this file is fairly standard, its syntax is almost the same as that which NCSA's Telnet uses. In order to properly configure this file you may need to refer to Charon's documentation. Nothing in CONFIG.TEL differs between a normal Charon installation and a Charon installation with XGATE, so we won't go into much detail about its contents. What is described in the following section are the field entries in CHARON.DAT that are significant when running Charon with XGATE. There are other configuration options available in CHARON.DAT which are not mentioned. You should keep an on-hand copy of Charon's documentation and refer to it for any questions regarding fields not described here. Once you have Charon's CONFIG.TEL and CHARON.DAT files edited correctly and have used XGATE's setup program XSETUP to create the job servers and queues, you are ready to run Charon. Do not follow any of the installation steps described in Charon's documentation that involve building print servers and print queues using Novell's PCONSOLE! XGATE's setup program XSETUP (described in XGATE's installation), should have already created the proper job servers and job queues. Configuring CHARON.DAT Configuring CHARON.DAT myname myname This variable tells Charon what its Internet name is. This should be set to the same fully-qualified host name that was entered for the "smtp_gateway_name" in XGATE.CFG. server server This variable starts a group of variables which define values associated with a particular Novell file server. Charon's native mode is normally capable of servicing more than one file server and this entry (along with its sub-entries) could then be defined more than once. The Charon documentation and sample CHARON.DAT file supplied with Charon may show more than one Novell file server defined. When Charon is used with XGATE, do not define more than one file server by using more than one "server" variable. MHS will perform any multi-host routing necessary. 4 XCHARON - Running XGATE With Charon ---------------------------------------------------------------------- Note: When Charon is run under XCharon, all login requests to any file server are intercepted and automatically returned with a success result. Defining more than one "server" entry will only confuse Charon by making it think it has successfully logged into a file server that it actually hasn't. An example structure of a "server" section in CHARON.DAT is: server enterprise ; Novell file server userid xcharon ; login name password "" ; password to use mailqueue smtp_in ; job queue to use poll 10 ; poll freq in secs When Charon is run by XCharon, the only variable that isn't overridden by XCharon is "poll". This might imply however that you could leave these fields blank - but if you do that Charon will not attempt to use the job queue. You can use whatever sounds good for the values of "server", "userid", "password", and "mailqueue" - they just shouldn't be blank (except for password). You normally would set the poll frequency to a value similar to that used in XGATE's configuration. mailer mailer This field starts Charon's mailer information section. An example mailer section follows: mailer ; The mailer section agent darius ; Our SMTP relay smtpin enterprise smtp_in ; SMTP inbound queue listcycles 2 ; msgs deliv/cycle listdelay 1 ; secs delay between debug ; enable SMTP debug max_smtpds 4 ; max SMTP daemons nobroadcast ; no Novell bcasts returnto postmaster ; rejected mail returnlines 0 ; returned lines timeout 600 ; max exec time 5 XCHARON - Running XGATE With Charon ---------------------------------------------------------------------- The "agent" field doesn't function any differently under XCharon then it would normally, but its important enough to mention. It controls which SMTP host Charon will attempt to relay all outbound SMTP mail to. The host name entered must match the name of a host defined in CONFIG.TEL, more specifically it must match one of the "name" fields (as opposed to the "hostip" or "host" fields) of a host entry in CONFIG.TEL. The "smtpin" field normally specifies the queue name where incoming SMTP messages are queued. XCharon will automatically override any values, correct or incorrect, entered for this variable - but token values (like in the "server" section mentioned previously) must be entered or Charon won't even try to use the queue. Note: Charon also allows for a "smtpout" field in the mailer section, which would normally provide a 2nd queue option to use for SMTP outbound messages. DO NOT define an "smtpout" field when using Charon with XCharon. It will only confuse Charon into thinking it has attached to more queues than it actually has because XCharon will intercept the queue attach request, map it to the normal smtpin queue, which will then fail because that queue has already been attached to. The rest of the mailer section fields control various operating options which don't have a direct or significant impact when using Charon with XCharon. Refer to Charon's documentation for more information if you want to tinker with any of their values. aliases aliases This field starts Charon's aliases section. This is the only other section containing variables which have an impact on Charon's operation under XCharon. An example aliases section follows: aliases ; The aliases section node mhs.com ; map our SMTP host name enterprise ; to our Novell server The "node" alias tells Charon to accept mail addressed to Charon's SMTP host name by associating it with a Novell file server name. If you don't specify the correct names for the node alias, Charon will refuse to accept inbound SMTP mail addressed to your users. 6 XCHARON - Running XGATE With Charon ---------------------------------------------------------------------- Note: Charon's documentation would also have you provide a "user" alias for the postmaster. This is unnecessary however in our case since XGATE will automatically remap mail addressed for the postmaster to the MHS administrator. Running Charon Running Charon When you run Charon, simply change directories to the one containing Charon's files and then run XCHARON.COM. XCharon will then log itself in under the proper object type, install its background handlers that make Charon work properly, and then run CHARON.EXE. When Charon tries to log in as a print server, XCharon intercepts the request and arbitrarily returns a successful login result (XCharon has already logged us in). When Charon terminates, XCharon will regain control and log itself out of the file server. XCharon also intercepts quite a few more things that change Charon's behavior significantly. These are described in the following section. What XCHARON Does To Fool CHARON What XCHARON Does To Fool CHARON This section provides a brief technical explanation of how XCharon and Charon interoperate. If you're the type that doesn't like to say "I don't know how it works", than this section should prove interesting reading. If technical mumbo-jumbo doesn't spin your prop, you can skip over it and leave these sordid details for the technocrats. Charon version 3.4 was designed with a lot of the same "frame-of-mind" found in most SMTP mailers. Which is, that whenever an inbound SMTP message delivery is attempted, that it should verify that the recipient is a valid user. In Charon's case, it does this by scanning the binderies of each Novell file server it is configured for. If it doesn't find the user, it rejects the message. If it does find the user, it attempts to write the message in the user's SYS:MAIL\userid subdirectory. This philosophy is totally opposite to that needed and expected in a single or multi-host MHS environment. MHS will determine whether the user is valid, after any appropriate user routing has been applied. So where the philosophy changes is that a single Charon installation should be capable of servicing any number of MHS hosts. All SMTP mail received by Charon should be considered destined for MHS, and must be passed directly to MHS without question, or verification. The only natural trait in Charon which is acceptable, and is left as is, is that if a message is delivered to Charon and the recipient's host name is not the one which Charon is configured to operate as, the message 7 XCHARON - Running XGATE With Charon ---------------------------------------------------------------------- is rejected. This is because the MHS host name is encoded in the "local-part" of the recipient's user name from the SMTP side - Charon's SMTP host name is the same for all inbound MHS messages. Another "flakey" thing that Charon does is try to use a Novell print server as its method of logging in, and then it expects to exchange messages with Pegasus mail by depositing inbound mail in the user's SYS:MAIL\userid subdirectory. And, it also looks for outbound SMTP messages in a Novell print queue. While this method does make some things easy because there's a readily available tool to manage and maintain print servers and print queues (Novell's PCONSOLE), it has a lot of undesirable caveats which most Novell administrator's would probably find unsettling. For 1), you end up with print queues which aren't print queues. Any type of menuing system that presents a listing of print queues for the user to select from will also show Charon's inbound and outbound work queues. The same goes for the print server object that Charon would like you to create. Another more serious problem, is that a print server normally has no disk privileges. Novell never anticipated that something would try to log in as a print server and also need read/write access to other areas of the file system. So there's no normal way to grant a print server any trusteeships to file server directories. Charon's answer to this is to run a utility program that comes with Charon, under supervisor privileges, that makes the print server object security equivalent to a user group. Then, disk privileges are granted to the user group. The problem with this is that BINDFIX thinks this is either an error, or a security violation, and removes the security equivalence each time its run. So how do we fix all this? And do it smoothly? The answer is a driver which you run in place of running Charon, which traps the Novell function request dispatcher and then runs Charon itself. When Charon terminates, the driver immediately terminates also. Whatever command line parameters given are passed through directly to Charon. Whatever exit code Charon returns is the same exit code returned by the driver. While the driver is active (which as we just described is only when Charon is active), it translates all of the undesirable "features" into a seamless method of allowing Charon to directly interoperate and communicate with XGATE. XCHARON.COM is the driver we're talking about. You could actually rename it to CHARON.COM and, since its a .COM file, it will automatically run before CHARON.EXE and you wouldn't have to change anything if you already have an automated method of starting Charon. When XCharon is run, it logs in as a job server called XCHARON (which is created by the XSETUP program). It then checks to make sure the rest of the queues are present which are built by XSETUP, and proceeds 8 XCHARON - Running XGATE With Charon ---------------------------------------------------------------------- to run CHARON.EXE if everything's ok. When Charon itself tries to log in as the print server defined in CHARON.DAT, XCharon catches the login attempt and immediately returns a successful login (because XCharon is already logged in appropriately). When Charon tries to reference any of the print queues defined in CHARON.DAT, XCharon remaps the requests to the job queues which XSETUP created. As time goes by and Charon receives an inbound SMTP message, it will try to confirm the user exists by making a bindery call - XCharon catches these functions and arbitrarily returns a success code. But it has to do a little more than that - it has to automatically differentiate which job queue to deal with between when Charon is receiving an inbound SMTP message and when Charon is attempting to service an outbound SMTP message. When Charon receives an inbound SMTP message, XCharon forces the message to go into the SMTP_IN inbound queue. Normally Charon doesn't service or scan for anything in the SMTP_IN queue - its only allowed to touch it when it's being fooled by XCharon into posting inbound messages in there. XGATE will then scan this queue for incoming messages and do the remainder of converting it to MHS. When XGATE has an outbound SMTP message, it posts it in the SMTP_OUT job queue, which is the queue XCharon fools Charon into using when it scans for outbound SMTP messages This may all sound a little complicated and prone to error - but it really isn't. The author is well versed with the Novell API and with systems-level coding - the whole thing blends together very seamlessly, reliably, and automatically. 9